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I. REAL PARTY IN INTEREST 

The real party in interest for this appeal is Microsoft Corporation. 
M. RELATED APPEALS. INTERFERENCES. AND JUDICIAL PROCEEDINGS 

Applicant, applicant's legal representative, and the real party in interest are unaware 
of any other appeal, interference, or judicial proceeding that may relate to, directly affect or 
be directly affected by, or have a bearing on the Board's decision in the present appeal. 

III. STATUS OF CLAIMS 

Claims 1-4 and 6-32 are pending in the present application and are the subject of 
this appeal. Claim 5 has been canceled. 

IV. STATUS OF AMENDMENTS 

Applicant filed an amendment on May 2, 2006, subsequent to the last Office Action 
mailed February 28, 2006. The Examiner has indicated that the amendment will be 
entered for purposes of this appeal. (Advisory Action, June 5, 2006.) 

V. SUMMARY OF CLAIMED SUBJECT MATTER 
A. Overview of the Invention and Prior Art 

1. The Invention 

Applicant's invention is directed to a technology that facilitates maintaining accurate 
presence information for a user who is logged on with two or more clients, such as in an 
instant messaging environment. (See, e.g., Specification, 8:8-12.) Instant messaging is a 
form of electronic communication that allows real time electronic communications among 
users. The ability to communicate in real time is one of the primary differences between 
instant messaging and other forms of electronic communication, such as email. (See, e.g., 
Specification, 2:12-20.) Notifying other instant messaging users of a particular user's 
status (e.g., available, away, busy) is an essential component of instant messaging. For 
example, if a first user is notified that a second user is away from his computer, the first 
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user may decide not to compose and send an instant message to the second user 
because the second user will not receive the message in real time. (See, e.g., 
Specification, 3:5-18.) A user's status may be referred to as "presence information," and 
may be provided to other users as indicative of the user's availability. (See, e.g., 
Specification, 2:24-3:4.) 

Providing other users with accurate presence information for a particular user may 
become difficult when the user is associated with or logged on to more than one client. 
(See, e.g., Specification, 4:3-9.) For example, a user may log on to the instant messaging 
environment with an identity (e.g., user@xxx.com) using a desktop computer and again 
with the same identity using a personal digital assistant. Each client may indicate a 
different status for the user. For example, the user may be idle on the desktop computer 
but busy on the personal digital assistant. Providing accurate presence information was 
not a problem with prior techniques because the prior techniques required that a user be 
logged on to only one device at a time. Applicant's technology allows a user to be logged 
on to two or more devices at the same time. 

Applicant's technology evaluates the user's status on each of the two or more 
clients, including any status update (e.g., a change in status from away to busy), to 
determine an accurate master, or overall, status for the user. (See, e.g., Specification, 
5:24-6:5.) For example, the user who is idle on a desktop computer but busy on a 
personal digital assistant may have an overall status of busy, because even though the 
user is idle at one client, the user is busy at another. To determine the master status, 
applicant's technology first creates and maintains a client view status for each client. Each 
client view status correlates to the status of the client, e.g., online, offline, away, invisible, 
busy, etc. (See, e.g., Specification, 5:17-22.) Applicant's technology determines the 
master status of the user by evaluating each of the client view statuses and any status 
update. (See, e.g., Specification, 5:24-6:2.) In some embodiments, applicant's technology 
determines the master status according to specified priority rules. For example, if the 
status of one client changes to offline, applicant's technology will not update the master 
status to offline unless the user is offline on all other clients. This allows a user who is, for 
example, busy on one client but offline on another to still be accurately reflected as busy. 
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(See, e.g., Specification, 19:10-20:13.) Once the master status has been determined, 
applicant's technology may provide the master status to the user and to other users for use 
in determining how best to communicate with the user. (See, e.g., Specification, 6:3-5.) 

2. The Bunnev Reference 

Bunney discloses a solution to a problem that may occur when a user is logged in 
with one of several addresses, and the other addresses assigned to the user are not in a 
logged in state. In such a situation, the user may not receive messages addressed to any 
of the user's non-logged in addresses. (Bunney, 1:24-30.) For example, a user may have 
the identities of "George@compu.xxx.com" and "Superman@sport.xxx.com." Bunney 
describes that under the prior art, if a user was logged in with the address 
"George@compu.xxx.com" and a message was sent to "Superman@sport.xxx.com," the 
user would not be notified of the message until the next time the user logged in with the 
address "Superman@sport.xxx.com." 

Bunney's solution is to notify a user who is logged in with the first of several 
addresses of a message received at a second, non-logged in address. (Bunney, 1:45-48.) 
Under the above example, if a user was logged in with the address 
"George@compu.xxx.com" and a message was sent to "Superman@sport.xxx.com," the 
user may be notified of the message through the user's "George@compu.xxx.com" 
identity. The user could then log out of the "George@compu.xxx.com" identity and log in 
using the identity of "Superman@sport.xxx.com" to review the message. To provide this 
notification, Bunney describes a server that maintains a table associating a user with each 
of several addresses assigned to the user. (Bunney 1:56-59.) When a message is sent to 
one of the user's non-logged in addresses, the server consults the table of assignments to 
identify the assigned addresses and then checks whether the user is currently logged in to 
one of those addresses. If so, the server may send a notification to the user's logged in 
address that the user has received a message at one of the user's non-logged in 
addresses. (Bunney, 1:60-67.) 

Under Bunney, when a user is logged in, the user may have one of four statuses: 
available, invisible, away, and busy. (Bunney, 7:5-30.) A status of invisible prevents a 
user from being visible to other users' searches and from receiving other users' 
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notifications. According to Bunney, if a user is invisible, other users will not know anything 
about the user, including that the user is online. 

In addition to, but distinctive from, the statuses described above, Bunney allows a 
user who is logged in through one address to associate a do not disturb sign with one or 
more of the user's other addresses. For example, a user logged in with the address 
"George@compu.xxx.com" can place a do not disturb sign that indicates he does not want 
to receive any message or notification addressed to his other address 
"Superman@sport.xxx.com." (Bunney, 9:25-35.) Bunney's Session Manager monitors 
whether a user has placed a do not disturb sign and communicates with the Notification 
Server, which uses the information to determine whether to send notifications to the user. 
(Bunney, 4:38-47.) 

3. The Runyan Reference 

Runyan describes improving security on NetWare networks. Runyan describes that 
one user can log in to a network from more than one workstation at the same time. As a 
security measure, Runyan suggests limiting the number of workstations from which one 
user may log in at the same time, using the same user identification. 

4. The Aravamudan Reference 

Aravamudan describes a messaging solution that features a user-selected priority 
system. A user may create groups of buddies (e.g., other users) and define specific 
attributes that are associated with the buddies in each group. (Aravamudan, 2:33-35.) 
One of the attributes to be defined by the user is a user-selected priority system. In the 
exemplary embodiment described, the user may assign one of three priorities to each 
group of buddies: low, high, or highest. These priorities determine whether another user 
has access to the user's presence information and how the users will interact with each 
other. For example, buddies who are assigned a low priority will never be able to see 
whether a user is online or offline, and will always communicate with the user via a user 
proxy. Buddies who are assigned a high priority will be able to see the user's online status 
anytime the user is online. Buddies who are assigned the highest priority can interface 
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with the user directly when the user is online and via user proxy when the user is offline. 
(Aravamudan, 2:35-49.) 

B. Independent Claims on Appeal 

The rejected independent claims are directed to maintaining accurate presence 
information for a user who is logged on to two or more clients. The independent claims are 
described as follows: 

1. Claim 1 

Claim 1 is directed to a method at a server computer system for updating a master 
status of an electronic messaging user not withstanding that a first client computer system 
and a second client computer system may indicate different statuses for the electronic 
messaging user. The server computer system is network connectable to a plurality of 
client computer systems. At least first and second client computer systems are configured 
to indicate a status for and to send and receive electronic messages for an electronic 
messaging user identified by a user identification. (See, e.g., Specification, 8:10-12.) The 
master status is the status that is reflected to other client computer systems. The method 
maintains at the server a first view status for the electronic messaging user identified by 
the user identification, the first view status indicating the status of the electronic messaging 
user as detected at the first client computer system when the user is logged on via the first 
client computer system as an electronic messaging user. The method also maintains at 
the server a second view status for the electronic messaging user identified by the user 
identification, the second view status indicating the status of the electronic messaging user 
as detected at the second client computer system when the user is logged on via the 
second client computer system as an electronic messaging user. (See, e.g., Specification, 
16:5-6.) The method receives at the server a first status update from the first client 
computer system, the first status update indicating that the first client computer system has 
detected a change in the status of the electronic messaging user identified by the user 
identification, the change in status corresponding to the first client computer system. In 
response to receiving a status update, the server evaluates at least the first status update, 
the first view status, and the second view status according to specified status rules to 
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determine the master status of the electronic messaging user identified by the user 
identification who is logged on via both the first client computer system and the second 
client computer system as an electronic messaging user. (See, e.g., Specification, 19:8- 
20:13.) The method stores the master status at the server in a master view that 
corresponds to the electronic messaging user identified by the user identification. The 
method reflects an indication of the master status to other electronic messaging users. 
(See, e.g., Specification, 8:12-16.) 

2. Claim 10 

Claim 10 is directed to a method at a server for updating the presence information 
of an electronic messaging user that is to be reflected to subscribers. The server is 
network connectable to a plurality of clients, each client in the plurality of clients 
maintaining a status for an electronic messaging user identified by a user identification, 
each client configured to receive electronic messages addressed to the electronic 
messaging user identified by the user identification, the electronic messaging user having 
presence information maintained at the server. The method creates at the server a view 
status for each of the one or more clients in the plurality of clients, each view status 
representing the status of the electronic messaging user identified by the user identification 
detected at a corresponding client, each view status being identified by a unique view 
identifier, the electronic messaging user identified by the user identification through at least 
two clients at the same time. (See, e.g., Specification, 8:10-12, 16:5-6.) The method 
consolidates at the server the presence information for the electronic messaging user 
identified by the user identification based on an evaluation each view status such that the 
consolidated presence information is representative of a current status of the electronic 
messaging user even if some view statuses differ, wherein the consolidated presence 
information is maintained in a master view. The method receives at the server a status 
update from one of the one or more clients. The method updates in the master view at the 
server the consolidated presence information for the electronic messaging user identified 
by the user identification based on an evaluation the status update and each view status. 
(See, e.g., Specification, 19:8-20:13.) 
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3. Claim 19 

Claim 19 is directed to a method in an instant messaging group for reflecting the 
master status to subscribers. The instant messaging group has a user associated with 
multiple clients, each client configured to detect a status of the user and to send and 
receive electronic messages for the user, the user having consolidated presence 
information representative of a master status stored at a server, the master status 
representing the status that is reflected to subscribers even if the user status detected at 
some of the multiple clients differs. For each of the multiple clients, the method creates at 
the server a client view status when each of the multiple clients sends a first status change 
to the server, each client view status representing the status of the user as detected at a 
corresponding client, the user being logged on to at least two clients at the same time to 
receive electronic messages. The method assigns at the server a view identifier to each 
client view status when the first status change is received at the server, wherein each view 
identifier associates one of the multiple clients with a corresponding client view status. 
{See, e.g., Specification,. 16:5-6.) The method sets at the server the master status based 
on an evaluation of each client view status. For each subsequent status change that is 
received from one of the multiple clients at the server, the method updates the master 
status in accordance with an evaluation of the subsequent status change and each client 
view status, wherein the presence information reflected to other subscribers corresponds 
to the master status. (See, e.g., Specification, 19:8-20:13.) 

4. Claim 27 

Claim 27 is directed to a computer program product for use in an instant messaging 
system for implementing a method for updating the presence information of a user. The 
instant messaging system has a user associated with one or more clients, each client in 
the one or more clients configured to detect a status of the user and to send and receive 
electronic messages for the user, the user having presence information reflected to 
subscribers. (See, e.g., Specification, 8:10-12.) The computer program product 
comprises a computer-readable medium carrying executable instructions that, when 
executed, cause a server to create at the server a view status for each of the one or more 
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clients, each view status representing the status of the user detected at the corresponding 
client, each view status being identified by a unique view identifier, the user being logged 
on to at least two clients at the same time to receive electronic messages. (See, e.g., 
Specification, 16:5-6.) The computer program product comprises a computer-readable 
medium carrying executable instructions that, when executed, cause a server to 
consolidate at the server presence information for the user is based on an evaluation of 
each view status such that the consolidated presence information is representative of the 
current status of the user. The computer program product comprises a computer-readable 
medium carrying executable instructions that, when executed, cause a server to receive at 
the server a status update from one of the one or more clients. The computer program 
product comprises a computer-readable medium carrying executable instructions that, 
when executed, cause a server to update at the server the consolidated presence 
information for the user according to the status update. The computer program product 
comprises a computer-readable medium carrying executable instructions that, when 
executed, cause a server to reflect at the server the updated consolidated presence 
information to the subscribers such that the appropriate presence information is provided 
to the subscribers even if some view statuses differ. (See, e.g., Specification, 19:8-20:13.) 

5. Claim 29 

Claim 29 is directed to a method in a server for generating a master presence 
status of a user who is online via multiple clients at the same time. For each of the 
multiple clients through which the user is currently online, the method receives at the 
server receives a client presence status of the user as reported by the client. The method 
generates the master presence status representing a current presence status of the user 
based on the received client presence statuses reported by the multiple clients. 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 



A. The Examiner's Rejections 

1. The Examiner rejected claims 1-4, 6-8, 10-14, 16-22, 24-27 and 29-32 1 
under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 6,487,584 to 
Bunney and "All quiet on the NetWare front" by Runyan. 

2. The Examiner rejected claims 9, 15, 23, and 28-32 under 35 U.S.C. § 103(a) 
as being unpatentable over Bunney, Runyan, U.S. Patent No. 6,301,609 to Aravamudan, 
and U.S. Patent No. 6,480,593 to Munday. 

B. The Issues on Appeal 

1. Whether Bunney suggests determining a master status in accordance with a 
status update and each client view status. The decision on this issue impacts all of the 
claims. 

2. Whether one would be motivated to combine Runyan's suggestion that a 
user may be logged on to several clients with Bunney's solution to a problem that occurs 
when a user is logged on to only one address. The decision on this issue impacts all of 
the claims. 

3. Whether Bunney suggests reflecting the master status of the user to other 
electronic messaging users. The decision on this issue impacts claims 1-4, 6-9, 16, and 
19-28. 



1 The Examiner has rejected claims 29-32 under the combination of Bunney and Runyan 
and also under the combination of Bunney, Runyan, Aravamudan, and Munday. For purposes of 
this appeal, applicant assumes that the Examiner intended to reject these claims under the 
combination of Bunney and Runyan even though the Examiner provides no explanation of the 
basis for rejecting these claims under Bunney and Runyan. 
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4. Whether the combination of Bunney, Runyan, and Aravamudan suggests 
changing the master status according to a detailed priority system. The decision on this 
issue impacts claims 9, 15, 23, and 28. 

VII. ARGUMENTS 

A. Obviousness Rejections 

1 . Legal Standards for Obviousness 

All of the claims on appeal stand rejected as obvious under 35 U.S.C. § 103(a). 35 
U.S.C. § 103(a) provides: 

A patent may not be obtained though the invention is not identically disclosed 
or described as set forth in section 102 of this title, if the differences between 
the subject matter sought to be patented and the prior art are such that the 
subject matter as a whole would have been obvious at the time the invention 
was made to a person having ordinary skill in the art to which said subject 
matter pertains. Patentability shall not be negatived by the manner in which 
the invention was made. 

"[T]he [Ejxaminer bears the initial burden of presenting a prima facie case of obviousness." 
In re Rijckaert, 9 F.3d 1531, 1532, 28 U.S.P.Q.2d (BNA) 1955, 1956 (Fed. Cir. 1993). '"A 
prima facie case of obviousness is established when the teachings from the prior art itself 
would appear to have suggested the claimed subject matter to a person of ordinary skill in 
the art.'" Id. (quoting In re Bell, 991 F.2d 781, 783, 26 U.S.P.Q.2d (BNA) 1529, 1531 (Fed. 
Cir. 1993)). 

To establish a prima facie case of obviousness, the Examiner must (1) identify prior 
art references that disclose all the elements of the claims, and (2) provide a suggestion or 
motivation to modify the references to produce the claimed invention. (MPEP § 2143.) 
With respect to the second requirement, the Examiner must provide a suggestion or 
motivation to combine from within the prior art, and may not rely on hindsight gleaned from 
applicants' invention itself. See, e.g., Uniroyal, Inc. v. Rudkin-Wiley Corp., 837 F.2d 1044, 
1050-51, 5 U.S.P.Q.2d 1434, 1438 (Fed. Cir. 1988). 
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Under these standards, applicants' invention would not have been obvious. The 
Examiner has not identified prior art references that disclose all the elements of the 
pending claims. The Examiner also has not provided any motivation from within the prior 
art to modify the cited references so as to produce the claimed invention. Therefore, the 
rejection of the claims should be reversed. 

2. Discussion of Issues 

In rejecting the pending claims, the Examiner has mapped the elements of the prior 
art to applicant's claim elements in inconsistent and contradictory ways. For example, the 
Examiner argues that Bunney's address with which the user is logged in corresponds to 
applicant's "master status." (Office Action, Feb. 28, 2006, p. 4.) However, the Examiner 
also argues that Bunney's providing a user's status (e.g., available, away, or busy) to other 
users corresponds to applicant's "reflecting" the master status. (Office Action, Feb. 28, 
2006, p. 4.) It is contradictory for the Examiner to take the position that Bunney's address 
corresponds to applicant's master status and then to take the position that Bunney's user 
status corresponds to applicant's master status. As another example, applicant's master 
status is determined by evaluating "a first status update, a first view status, and a second 
view status." The Examiner, however, points to Bunney's address as corresponding to 
applicant's "first view status." Thus, the Examiner argues that Bunney's address 
corresponds to both applicant's master status and first view status. Because applicant's 
master status is determined by evaluating the first view status in addition to other factors, 
as stated above, the Examiner's suggestion that applicant's master status is the same as 
applicant's first view status is inconsistent. Because of the inconsistent positions taken by 
the Examiner, it is difficult for applicant to respond to the Examiner's arguments in as 
straightforward a manner as applicant would like. Applicant has attempted to respond to 
each of the Examiner's contradictory arguments. 
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a. Bunnev fails to teach or suggest determining a master 
status in accordance with an evaluation of a status 
update and each client view status. 

All of the claims recite determining a master status in accordance with an evaluation 
of a status update and each client view status. For example, claim 1 recites: 

in response to receiving the first status update, the server evaluating at least 
the first status update, the first view status, and the second view status 
according to specified status rules to determine the master status of the 
electronic messaging user . . . 
In other words, the server receives a status update when one of the user's client computer 
systems detects a change in the status of the electronic messaging user, e.g., a change 
from away to busy. (Specification, 14:1-2.) The server evaluates the status update and 
the statuses of all other client computer systems, which are obtained from each client view 
status maintained by the server. The server uses specified rules to reconcile differing 
statuses and determine the master status. 

Bunney does not describe any element that corresponds to applicant's "master 
status." Applicant's master status of an electronic messaging user is determined by 
"evaluating at least the first status update, the first view status, and the second view 
status," as described above. The Examiner points to Bunney at 9:1-20 as disclosing a 
master status, explaining that "Bunney discloses the server checking a table to see which 
address to send a notification to." (Office Action, Feb. 28, 2006, p. 4.) It is apparently the 
Examiner's position that Bunney's "address to send a notification to" (i.e., the address with 
which a user has logged in) corresponds to applicant's "master status." However, these 
concepts are distinct. Applicant's master status is not an address; rather, it is an overall 
status (e.g., online, offline, away, busy, invisible) that is formed by evaluating the status 
update and the client view statuses according to specified rules. In contrast, the address 
through which the user has logged on in Bunney is not determined by evaluating a status 
update or client view statuses, nor is it determined according to specified status rules. 

Further, the Examiner believes that Bunney's logged on address corresponds to 
applicant's "first view status," in addition to corresponding to applicant's master status, as 
described above. When discussing applicant's claim language "maintaining at the server a 
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first view status," the Examiner states that "Bunney discloses an address a user has 
logged in with on a certain terminal." (Office Action, Feb. 28, 2006, p. 3.) Applicant's first 
view status and master status are two different statuses. The master status is determined 
by "evaluating at least the first status update, the first view status, and the second view 
status." Clearly, applicant's first view status and master status are distinct. The Examiner 
has pointed to a single address as corresponding to both statuses, without explaining how 
a single address can correspond to both statuses. 

Even if Bunney disclosed a master status, Bunney does not disclose determining a 
master status in accordance with an evaluation of a status change and each client view 
status. Bunney's Session Manager does maintain information about the status of a user, 
which may include available, away, invisible, or busy. (Bunney, 7:5-9.) Except when a 
user's status is invisible, the status is displayed to other network users. However, even if 
Bunney allowed a user to be logged in to two or more clients at the same time, Bunney 
offers no teaching that it would attempt to evaluate a status change and each client view 
status to determine a master status. Bunney offers no guidance to remedy a situation, for 
example, where a user is "busy" on one client and "available" on another. 

The Examiner does not rely on Runyan for curing this deficiency of Bunney. 
Indeed, Runyan cannot cure this deficiency, as it neither teaches nor suggests determining 
a master status for a user. 

b. The Examiner's suggestion to modify Bunney with 
Runvan's suggestion that a user may be logged on to 
several clients would obviate the need for Bunney's 
solution, which the Examiner relies upon in rejecting the 
claims. 

All of the claims recite that an electronic messaging user is logged on to at least two 
clients at the same time. For example, claim 1 recites: 

the electronic messaging user ... who is logged on via both the first client 
computer system and the second client computer system as an electronic 
messaging user. 

For example, a user may be logged on to an instant messaging environment through both 
a desktop computer and a personal digital assistant. Applicant's claims are directed to 
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maintaining a master status for the user even though the status of the user (e.g., online, 
offline, away, busy) may differ on the desktop computer and the personal digital assistant. 

The Examiner acknowledges that Bunney fails to teach the limitation of an 
electronic messaging user logged on to at least two clients at the same time. The 
Examiner points to Runyan to cure this deficiency. (Office Action, Feb. 28, 2006, p. 4.) 
Runyan describes that a user may be logged in to a NetWare network, or a network 
operating system, from one or more different workstations. It would, however, be 
contradictory to combine Bunney's technique that solves a problem that occurs when a 
user is logged in on one address with Runyan's technique that allows a user to log in at 
several workstations. Bunney is designed to address a problem that occurs when a user 
has several addresses, the user is logged in to a network under only one address, and a 
message is sent to another of the user's addresses. Bunney describes the problem it 
intends to solve as follows: 

when the user has logged in with one of said several addresses, and the 
other addresses assigned to the same user are not in a loqqed-in state , no 
message or notification from a server or another user terminal can be 
forwarded to the user, when the notification or message is addressed to one 
of the addresses which are in a non-logged-in state. 
(Bunney, 1:24-30, emphasis added.) In explaining its solution to this problem, Bunney 
describes a user logged in to a network with one of the user's several addresses. A server 
or another user sends a message to a second of the user's addresses, i.e., one of the 
user's addresses that is in a non-logged in state. The server consults its table of 
assignment information to determine whether the user associated with the second address 
is logged in to the network through another address. If so, the server will notify the user 
through the user's logged in address that a message has been sent to the user's second, 
non-logged in address. (Bunney, 1:60-67.) Further, Bunney emphasizes that its Session 
Manager "allows a user to log into the system once ..." (Bunney, 4:35-36, emphasis 
added.) 

It is the Examiner's position that one would be motivated to combine Bunney and 
Runyan to have an electronic messaging user logged on to at least two clients at the same 
time "because it allows the user to be logged onto multiple devices and it allows other 
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users to find them based on their state." (Office Action, Feb. 28, 2006, p. 4.) Combining 
Bunney and Runyan to allow a user to be logged on to multiple devices using different 
addresses would, however, entirely avoid the problem Bunney attempts to solve. If a user 
were logged on to a device for each of his different addresses, and a message were sent 
to any of the user's addresses, the user would receive the message. There would be no 
need for Bunney's solution, i.e., providing notification to the user that a message has been 
received at one of the user's addresses that is not in a logged on state. The Examiner's 
suggestion is thus not a suggestion to modify Bunney, but rather a suggestion to entirely 
avoid the problem Bunney attempts to solve by requiring the user to log on through 
multiple addresses. 

Furthermore, the Examiner's rejection relies upon both Bunney's solution and 
Runyan's multiple log on in rejecting the claims. For example, the Examiner relies upon 
Bunney's solution of "checking the table to see which address to send a notification to." 
(Office Action, Feb. 28, 2006, p. 4.) Such checking of a table would not be needed, 
however, if Bunney was modified to allow a user to log on to multiple addresses as 
suggested by Runyan. Thus, the Examiner is applying the suggested combination in 
contradictory ways. 

c. Bunney fails to teach or suggest reflecting the master 
status of the user to other electronic messaging users. 

Many of the claims recite reflecting the master status of the user to other electronic 
messaging users. For example, claim 1 recites: 

reflecting an indication of the master status for the electronic messaging user 
identified by the user identification to other electronic messaging users. 
One of the benefits of an electronic messaging environment is that a user's status is 
reflected, e.g., displayed, to other users. When the user is logged on through two or more 
clients, applicant's technology reflects a user's master status to other users in the 
environment, rather than reflecting the status information of the client or clients separately. 

Even if Bunney were to create a master status, it does not disclose reflecting such a 
status to other users. The portions of Bunney cited by the Examiner do not teach or 
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suggest reflecting the master status of the user to other electronic messaging users. 
(Bunney, 7:5-30; 9:25-35.) The first cited portion of Bunney describes that the Session 
Manager maintains information about the user's status, which may be available, away, 
invisible, or busy. (Bunney, 7:5-30.) This status information is provided to other users. 
However, the information maintained by Bunney's Session Manager and reflected to other 
users is simply the status of one of the user's clients; it is not a master status, determined 
by evaluating the status of each of the user's two or more clients. 

In addition, the Examiner previously indicated that applicant's master status was 
equivalent to Bunney's logged in address, as described above. It is inconsistent for the 
Examiner to now indicate that the master status reflected to other users is in the form of 
status information (e.g., available, away, or busy). Further, even if applicant's master 
status were equivalent to Bunney's logged in address, Bunney's logged in address is never 
reflected to other users. Accordingly, Bunney fails to teach or suggest reflecting the 
logged in address of the user, which the Examiner believes corresponds to applicant's 
master status, to other electronic messaging users. 

The second portion of Bunney cited by the Examiner describes a "do not disturb 
sign" that may be used by the user. (Bunney, 9:25-35.) A user logged in through one 
address may associate a do not disturb sign with one or more of the user's other 
addresses. For example, a user logged in with the address "George@compu.xxx.com" 
can place a do not disturb sign that indicates that the user does not want to receive any 
message or notification addressed to the user's other address 
"Superman@sport.xxx.com." A do not disturb sign is not status information (e.g., 
available, away, or busy); instead, it is a separate signal used to communicate with the 
server. The presence of a do not disturb sign is monitored by the Session Manager and is 
communicated to the Notification Server, which uses the information to determine whether 
to send notifications to the user. (Bunney, 4:38-47.) The do not disturb sign is not 
reflected to other users; other users only have access to the status of the user, such as 
available, away, or busy. Further, the do not disturb sign is not equivalent to applicant's 
master status. Even if Bunney were to permit an electronic messaging user to be logged 
on to two or more clients at the same time, Bunney offers no teaching about how a do not 
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disturb sign on one of the user's clients (i.e., non-status information) would be reconciled 
with status information presented by another of the user's clients. Indeed, it would be 
incongruous to attempt to reconcile these two diverse concepts. 

The Examiner does not rely on Runyan for curing this deficiency of Bunney. 
Indeed, Runyan cannot cure this deficiency, as it neither teaches nor suggests reflecting a 
master status for a user to other electronic messaging users. 

d. Bunnev, Runyan. and Aravamudan fail to teach or 
suggest updating the master status according to a 
detailed priority system. 

Several of the claims recite updating the master status according to a detailed 
priority system. For example, claim 15 recites: 

... changing the presence information according to a priority system further 
comprises at least one of: 

changing the presence information to offline if the status update 

indicates the electronic messaging user is invisible; 

changing the presence information to offline if the status update 
indicates the electronic messaging user is offline and the remaining 
view statuses indicate the electronic messaging user is offline; 
changing the presence information to idle if the status update 
[indicates] the electronic messaging user is idle and the remaining 
view statuses indicate the electronic messaging user is idle or offline; 
and 

changing the presence information to match the status update. 
Each of these rules for changing the master status is a specific example of updating the 
master status by evaluating "a first status update, a first view status, and a second view 
status." For example, the first rule applies where the first status update, and thus the first 
view status, is invisible; the second view status may be any status. When the first status 
update is invisible, it indicates that the user does not want to be seen by other users. 
Thus, according to the first rule, the master status will be changed to offline. 

It is the Examiner's position that Bunney discloses the first of these priority rules. 
The Examiner points to Bunney at 7:10-15 as disclosing this priority rule, explaining that 
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"Bunney discloses the use of being invisible to others." (Office Action, Feb. 28, 2006, p. 
13.) While the cited portion of Bunney does describe that a user may have a status of 
invisible, Bunney does not disclose changing the master status to offline if the first status 
update indicates the user is invisible. Bunney does not create or maintain a master status, 
nor does it receive a status update. Bunney's invisible status merely prevents a user from 
being visible to other users' searches and from receiving other users' notifications. 
According to Bunney, if a user is invisible, other users will not know anything about the 
user, not even that the user is online. The first priority rule is not disclosed by Bunney. 

It is the Examiner's position that Aravamudan discloses the fourth and fifth of these 
priority rules. The Examiner points to Aravamudan's abstract as teaching "the use of 
instant messaging in conjunction with access to data and communication network 
channels and modes" and to Aravamudan at 4:45-67 and 10:1-51 as teaching "the use of 
the proxy always appearing to the buddy and real presence being advertised to other[s] 
who have identified the user as a buddy." (Office Action, Feb. 28, 2006, p. 14.) The 
Examiner believes that one would be motivated to modify Bunney and Runyan in view of 
Aravamudan "because it would result in the most accurate presence for a user." (Office 
Action, Feb. 28, 2006, p. 15.) However, rather than a priority system executed by the 
server as in applicant's technology, Aravamudan describes a priority system that is 
selected by the user. The user may assign a priority to each buddy or group of buddies. 
In the exemplary embodiment described, the user may select among low, high, and 
highest priorities. These priorities determine to what status information other users have 
access and how other users may communicate with the user. Also unlike applicant's 
technology, Aravamudan's priority system does not reconcile differing user statuses 
associated with two or more clients. Instead, priorities are assigned to other users by the 
user, and such priorities do not relate to the other user's status (e.g., available, away, 
busy). Instead, the priorities determine how another user may interact with the user who 
assigned the priority. Unlike applicant's technology, Aravamudan does not teach or 
suggest a priority system executed by a server and, in particular, does not teach or 
suggest the particular priority rules as claimed. 
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3. 



Response to the Section 103(a) Rejection of Claims 1-4, 6-8, 10-14, 
16-22, 24-27 and 29-32 Over Bunnev and Runvan 



Claims 1-4, 6-8, 10-14, 16-22, and 24-27, and 29-32 were rejected under 35 U.S.C. 
§ 103(a) over Bunney and Runyan. For the reasons described below, the Examiner has 
failed to establish that these claims are obvious over Bunney and Runyan. Therefore, the 
section 103(a) rejection of these claims should be reversed. 



Claims 1-4 and 6-8 recite "the electronic messaging user ... who is logged on via 
both the first client computer system and the second client computer system as an 
electronic messaging user." As discussed above in section 2.b, one would not be 
motivated to combine Runyan's suggestion that a user may be logged on to several clients 
with Bunney's system that allows a user to be logged on to only one address. Therefore, 
the section 103(a) rejection of these claims should be reversed. 

These claims also recite "in response to receiving the first status update, the server 
evaluating at least the first status update, the first view status, and the second view status 
according to specified status rules to determine the master status of the electronic 
messaging user As discussed above in section 2. a, neither Bunney nor Runyan 
teaches or suggests this feature. Therefore, the section 103(a) rejection of these claims 
should be reversed. 

These claims also recite "reflecting an indication of the master status for the 
electronic messaging user ... to other electronic messaging users." As discussed above in 
section 2.c, neither Bunney nor Runyan teaches or suggests this feature. Therefore, the 
section 103(a) rejection of these claims should be reversed. 



Claims 10-14 and 17-18 recite "the electronic messaging user being logged on as 
an electronic messaging user ... through at least two clients at the same time." As 
discussed above in section 2.b, one would not be motivated to combine Runyan's 
suggestion that a user may be logged on to several clients with Bunney's system that 



a. 



Claims 1-4 and 6-8 



b. 



Claims 10-14 and 17-18 
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allows a user to be logged on to only one address. Therefore, the section 103(a) rejection 
of these claims should be reversed. 

These claims also recite: 

consolidating at the server the presence information for the electronic messaging 
user ... based on an evaluation of each view status such that the consolidated 
presence information is representative of a current status of the electronic 
messaging user even if some view statuses differ, wherein the consolidated 
presence information is maintained in a master view; 

receiving at the server a status update from one of the one or more clients; and 

updating in the master view at the server the consolidated presence information for 
the electronic messaging user ... based on an evaluation of the status update and 
each view status. 

As discussed above in section 2. a, neither Bunney nor Runyan teaches or suggests this 
feature. Therefore, the section 103(a) rejection of these claims should be reversed. 

c. Claim 16 

Claim 16 recites the language of its base claim 10 and further recites "reflecting the 
updated presence information in the master view to the subscribers." As discussed above 
in section 2.c, neither Bunney nor Runyan teaches or suggests this feature. Therefore, the 
section 103(a) rejection of these claims should be reversed. 

d. Claims 19-22 and 24-26 

Claims 19-22 and 24-26 recite "the user being logged onto at least two clients at the 
same time to receive electronic messages." As discussed above in section 2.b, one would 
not be motivated to combine Runyan's suggestion that a user may be logged on to several 
clients with Bunney's system that allows a user to be logged on to only one address. 
Therefore, the section 103(a) rejection of these claims should be reversed. 

These claims also recite: 

setting at the server the master status based on an evaluation of each client view 
status; and 

for each subsequent status change received from one of the multiple clients at the 
server, updating the master status in accordance with an evaluation of the 
subsequent status change and each client view status. 
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As discussed above in section 2. a, neither Bunney nor Runyan teaches or suggests this 
feature. Therefore, the section 103(a) rejection of these claims should be reversed. 

These claims also recite "the presence information reflected to the subscribers 
corresponds to the master status." As discussed above in section 2.c, neither Bunney nor 
Runyan teaches or suggests this feature. Therefore, the section 103(a) rejection of these 
claims should be reversed. 

e. Claim 27 

Claim 27 recites "the user being logged onto at least two clients at the same time to 
receive electronic messages." As discussed above in section 2.b, one would not be 
motivated to combine Runyan's suggestion that a user may be logged on to several clients 
with Bunney's system that allows a user to be logged on to only one address. Therefore, 
the section 103(a) rejection of these claims should be reversed. 

This claim also recites: 

consolidate at the server presence information for the user based on an evaluation 
of each view status such that the consolidated presence information is 
representative of a current status of the user; 

receive at the server a status update from one of the one or more clients; 

update at the server the consolidated presence information for the user according to 
the status update. 

As discussed above in section 2. a, neither Bunney nor Runyan teaches or suggests this 
feature. Therefore, the section 103(a) rejection of these claims should be reversed. 

This claim also recites "reflect at the server the updated consolidated presence 
information to the subscribers such that the appropriate presence information is provided 
to the subscribers even if some view statuses differ." As discussed above in section 2 c, 
neither Bunney nor Runyan teaches or suggests this feature. Therefore, the section 
103(a) rejection of these claims should be reversed. 



41 826-8883. US00/LEGAL1 2268909. 1 



-21- 



Application No.: 09/318,447 



Docket No.: 418268883US 



f. 



Claims 29-32 



Claims 29-32 recite "a user who is online via multiple clients at the same time." As 
discussed above in section 2.b, one would not be motivated to combine Runyan's 
suggestion that a user may be logged on to several clients with Bunney's system that 
allows a user to be logged on to only one address. Therefore, the section 103(a) rejection 
of these claims should be reversed. 

These claims also recite "generating the master presence status representing a 
current presence status of the user based on the received client presence statuses 
reported by the multiple clients." As discussed above in section 2. a, neither Bunney nor 
Runyan teaches or suggests this feature. Therefore, the section 103(a) rejection of these 
claims should be reversed. 

4. Response to the Section 103(a) Rejection of Claims 9, 15, 23, and 28 
Over Bunney, Runyan, Aravamudan, and Munday 

Claims 9, 15, 23, and 28 were rejected under 35 U.S.C. § 103(a) over Bunney, 
Runyan, Aravamudan, and Munday. For the reasons described below, the Examiner has 
failed to establish that these claims are obvious over Bunney, Runyan, and Aravamudan. 
Therefore, the section 103(a) rejection of these claims should be reversed. 



Claims 9 recites the language of its base claim 1 and further recites updating the 

master status according to a detailed priority system. Claim 9 recites: 

... changing the master status according to a priority system further 
comprises: 



changing the master status to offline if the first status update indicates 
the electronic messaging user ... is invisible; 

refraining from changing the master status if the first status update 
indicates electronic messaging user ... is offline; 

refraining from changing the master status if the first status update 
indicates the electronic messaging user ... is idle; 

changing the master status to offline if the first status update indicates 
the electronic messaging user ... is offline and one or more remaining 
view statuses associated with the messaging client, including the 



a. 



Claims 9 
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second view status, indicate the electronic messaging user ... is 
offline; and 

changing the master status to idle if the first status update indicates 
the electronic messaging user ... is idle and one or more remaining 
view statuses associated with the messaging client, including the 
second view status, indicate the electronic messaging user ... is idle 
or offline. 

As discussed above in section 2.d, Bunney, Runyan, and Aravamudan each fail to teach or 
suggest this feature. Therefore, the section 103(a) rejection of these claims should be 
reversed. 

b. Claim 15 

Claim 15 recites the language of its base claim 14 and further recites updating the 
master status according to a detailed priority system. Claim 15 recites: 

... changing the presence information according to a priority system further 
comprises at least one of: 

changing the presence information to offline if the status update 
indicates the electronic messaging user is invisible; 

refraining from changing the presence information if the status update 
indicates the electronic messaging user is offline; 

refraining from changing the presence information if the status update 
indicates the electronic messaging user is idle; 

changing the presence information to offline if the status update 
indicates the electronic messaging user is offline and the remaining 
view statuses indicate the electronic messaging user is offline; 

changing the presence information to idle if the status update 
[indicates] the electronic messaging user is idle and the remaining 
view statuses indicate the electronic messaging user is idle or offline; 
and 

changing the presence information to match the status update. 
As discussed above in section 2.d, Bunney, Runyan, and Aravamudan each fail to teach or 
suggest this feature. Therefore, the section 103(a) rejection of these claims should be 
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c. 



Claim 23 



Claim 23 recites the language of its base claim 19 and further recites updating the 

master status according to a detailed priority system. Claim 23 recites: 

... changing the master status according to a priority system further 
comprises at least one of: 



changing the master status to offline if the subsequent status update 
indicates the user is invisible; 

refraining from changing the master status if the status update 
indicates the user is offline; 

refraining from changing the master status if the subsequent status 
update indicates the user is idle; 

changing the master status to offline if the subsequent status update 
indicates the user is offline and the remaining client view statuses 
indicate the user is offline; 

changing the master status to idle if the subsequent status update 
indicates the user is idle and the remaining client view statuses 
indicate the user is idle or offline; and 

changing the master status to match the subsequent status update. 



As discussed above in section 2.d, Bunney, Runyan, and Aravamudan each fail to teach or 
suggest this feature. Therefore, the section 103(a) rejection of these claims should be 



Claim 28 recites the language of its base claim 27 and further recites updating the 
master status according to a detailed priority system. Claim 28 recites: 

... updating the presence information further comprises: 



changing the presence information to offline if the status update 
indicates the user is invisible; 

refraining from changing the presence information if the status update 
indicates the user is offline; 

refraining from changing the presence information if the status update 
indicates the user is idle; 



reversed. 



d. 



Claim 28 
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changing the presence information to offline if the status update 
indicates the user is offline and the remaining view statuses indicate 
the status of the user is offline; 

changing the presence information to idle if the status update indicates 
the user is idle and the remaining view statuses indicate the user is 
idle or offline; and 

changing the presence information to match the status update. 



As discussed above in section 2.d, Bunney, Runyan, and Aravamudan each fail to teach or 
suggest this feature. Therefore, the section 103(a) rejection of these claims should be 
reversed. 

VIII. CONCLUSION 

The Examiner's section 103(a) rejection should be reversed primarily because the 
relied-upon art does not establish that the following claimed features are obvious: (1) an 
electronic messaging user logged on to at least two clients at the same time, (2) 
determining a master status in accordance with an evaluation of a status update and each 
client view status, (3) reflecting the master status of the user to other electronic messaging 
users, and (4) updating the master status according to a detailed priority system. 
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APPENDIX A 



CLAIMS 

1. (Previously Presented) At a server computer system that is network 
connectable to a plurality of client computer systems, at least first and second client 
computer systems being configured to indicate a status for and to send and receive 
electronic messages for an electronic messaging user identified by a user identification, a 
method for updating a master status of the electronic messaging user not withstanding that 
the first client computer system and second client computer system may indicate different 
statuses for the electronic messaging user, the master status being the status that is 
reflected to other client computer systems, the method comprising: 

maintaining at the server a first view status for the electronic messaging user 
identified by the user identification, the first view status indicating the status 
of the electronic messaging user as detected at the first client computer 
system when the user is logged on via the first client computer system as an 
electronic messaging user; 
maintaining at the server a second view status for the electronic messaging user 
identified by the user identification, the second view status indicating the 
status of the electronic messaging user as detected at the second client 
computer system when the user is logged on via the second client computer 
system as an electronic messaging user; 
receiving at the server a first status update from the first client computer system, the 
first status update indicating that the first client computer system has 
detected a change in the status of the electronic messaging user identified by 
the user identification, the change in status corresponding to the first client 
computer system; 

in response to receiving the first status update, the server evaluating at least the 
first status update, the first view status, and the second view status according 
to specified status rules to determine the master status of the electronic 
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messaging user identified by the user identification who is logged on via both 

the first client computer system and the second client computer system as an 

electronic messaging user; 
storing the master status at the server in a master view corresponding to the 

electronic messaging user identified by the user identification; and 
reflecting an indication of the master status for the electronic messaging user 

identified by the user identification to other electronic messaging users. 

2. (Previously Presented) A method as defined in claim 1 , further comprising: 
associating a first view identifier with the first view status; and 

associating a second view identifier with the second view status. 

3. (Previously Presented) A method as defined in claim 1 , further comprising: 
updating the first view status in accordance with the first status update. 

4. (Previously Presented) A method as defined in claim 1, wherein evaluating 
further comprises determining whether the master status should reflect the first status 
update. 

5. (Canceled) 

6. (Previously Presented) A method as defined in claim 1, wherein the storing 
further comprises changing the master status to the status indicated in the first status 
update. 

7. (Previously Presented) A method as defined in claim 1, wherein the storing 
further comprises retaining the master status even though the status indicated in the first 
status update differs from the master status. 
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8. (Previously Presented) A method as defined in claim 1, wherein the 
evaluating further comprises changing the master status according to a priority system. 

9. (Previously Presented) A method as defined in claim 8, wherein changing 
the master status according to a priority system further comprises: 

changing the master status to offline if the first status update indicates the electronic 
messaging user identified by the user identification is invisible; 

refraining from changing the master status if the first status update indicates 
electronic messaging user identified by the user identification is offline; 

refraining from changing the master status if the first status update indicates the 
electronic messaging user identified by the user identification is idle; 

changing the master status to offline if the first status update indicates the electronic 
messaging user identified by the user identification is offline and one or more 
remaining view statuses associated with the messaging client, including the 
second view status, indicate the electronic messaging user identified by the 
user identification is offline; and 

changing the master status to idle if the first status update indicates the electronic 
messaging user identified by the user identification is idle and one or more 
remaining view statuses associated with the messaging client, including the 
second view status, indicate the electronic messaging user identified by the 
user identification is idle or offline. 
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10. (Previously Presented) At a server that is network connectable to a plurality 
of clients, each client in the plurality of clients maintaining a status for an electronic 
messaging user identified by a user identification, each client configured to receive 
electronic messages addressed to the electronic messaging user identified by the user 
identification, the electronic messaging user having presence information maintained at the 
server, a method for updating the presence information that is to be reflected to 
subscribers, the method comprising the steps of: 

creating at the server a view status for each of the one or more clients in the 
plurality of clients, each view status representing the status of the electronic 
messaging user identified by the user identification detected at a 
corresponding client, each view status being identified by a unique view 
identifier, the electronic messaging user being logged on as an electronic 
messaging user identified by the user identification through at least two 
clients at the same time; 
consolidating at the server the presence information for the electronic messaging 
user identified by the user identification based on an evaluation of each view 
status such that the consolidated presence information is representative of a 
current status of the electronic messaging user even if some view statuses 
differ, wherein the consolidated presence information is maintained in a 
master view; 

receiving at the server a status update from one of the one or more clients; and 
updating in the master view at the server the consolidated presence information for 
the electronic messaging user identified by the user identification based on 
an evaluation of the status update and each view status. 

11. (Previously Presented) A method as defined in claim 10, wherein creating 
further comprises receiving a first status change at the server, the first status change being 
representative of an initial status of one of the one or more clients. 
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12. (Previously Presented) A method as defined in claim 10, wherein 
consolidating the presence information further comprises comparing each view status to 
determine a current status of the user, the current status corresponding to the presence 
information. 

13. (Original) A method as defined in claim 10, wherein each status update is 
reflected in an associated client view status, the associated client view status being 
identified by a view identifier sent with each status update. 

14. (Previously Presented) A method as defined in claim 10, wherein updating 
further comprises changing the presence information according to a priority system. 

15. (Previously Presented) A method as defined in claim 14, wherein changing 
the presence information according to a priority system further comprises at least one of: 

changing the presence information to offline if the status update indicates the 

electronic messaging user is invisible; 
refraining from changing the presence information if the status update indicates the 

electronic messaging user is offline; 
refraining from changing the presence information if the status update indicates the 

electronic messaging user is idle; 
changing the presence information to offline if the status update indicates the 

electronic messaging user is offline and the remaining view statuses indicate 

the electronic messaging user is offline; 
changing the presence information to idle if the status update the electronic 

messaging user is idle and the remaining view statuses indicate the 

electronic messaging user is idle or offline; and 
changing the presence information to match the status update. 
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16. (Previously Presented) A method as defined in claim 10, wherein updating 
further comprises reflecting the updated presence information in the master view to the 
subscribers. 

17. (Previously Presented) A method as defined in claim 10, wherein updating 
further comprises changing the client view status associated with the status change, such 
that the client view status accurately reflects the status change. 

18. (Previously Presented) A computer-readable medium having computer 
executable instructions for performing the method recited in claim 10. 

19. (Previously Presented) In an instant messaging group having a user 
associated with multiple clients, each client configured to detect a status of the user and to 
send and receive electronic messages for the user, the user having consolidated presence 
information representative of a master status stored at a server, the master status 
representing the status that is reflected to subscribers even if the user status detected at 
some of the multiple clients differs, a method for reflecting the master status to 
subscribers, the method comprising the steps of: 

for each of the multiple clients, creating at the server a client view status at a server 
when each of the multiple clients sends a first status change to the server, 
each client view status representing the status of the user as detected at a 
corresponding client, the user being logged onto at least two clients at the 
same time to receive electronic messages; 

assigning at the server a view identifier to each client view status when the first 
status change is received at the server, wherein each view identifier 
associates one of the multiple clients with a corresponding client view status; 

setting at the server the master status based on an evaluation of each client view 
status; and 

for each subsequent status change received from one of the multiple clients at the 
server, updating the master status in accordance with an evaluation of the 
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subsequent status change and each client view status, wherein the presence 
information reflected to the subscribers corresponds to the master status. 

20. (Original) A method as defined in claim 19, wherein the client view status is 
representative of a current status of an associated client. 

21. (Previously Presented) A method as defined in claim 19, wherein setting the 
master status further comprises reflecting the master status to the subscribers. 

22. (Previously Presented) A method as defined in claim 19, wherein updating 
the master status further comprises changing the master status according to a priority 
system. 

23. (Previously Presented) A method as defined in claim 22, wherein changing 
the master status according to a priority system further comprises at least one of: 

changing the master status to offline if the subsequent status update indicates the 
user is invisible; 

refraining from changing the master status if the status update indicates the user is 
offline; 

refraining from changing the master status if the subsequent status update indicates 
the user is idle; 

changing the master status to offline if the subsequent status update indicates the 
user is offline and the remaining client view statuses indicate the user is 
offline; 

changing the master status to idle if the subsequent status update indicates the 
user is idle and the remaining client view statuses indicate the user is idle or 
offline; and 

changing the master status to match the subsequent status update. 
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24. (Original) A method as defined in claim 19, wherein the master status 
reflected to the subscribers is representative of a current status of the user. 



25. (Previously Presented) A method as defined in claim 19, further comprising 
selecting one of the client view statutes to be represented in the master status. 

26. (Previously Presented) A computer-readable medium having computer- 
executable instructions for performing the method recited in claim 1 9. 

27. (Previously Presented) A computer program product for use in an instant 
messaging system having a user associated with one or more clients, each client in the 
one or more clients configured to detect a status of the user and to send and receive 
electronic messages for the user, the user having presence information reflected to 
subscribers, the computer program product for implementing a method for updating the 
presence information, the computer program product comprising: 

a computer-readable medium carrying executable instructions that, when executed, 
cause a server to perform the following: 

create at the server a view status for each of the one or more clients, each 
view status representing the status of the user detected at a 
corresponding client, each view status being identified by a unique 
view identifier, the user being logged onto at least two clients at the 
same time to receive electronic messages; 

consolidate at the server presence information for the user based on an 
evaluation of each view status such that the consolidated presence 
information is representative of a current status of the user; 

receive at the server a status update from one of the one or more clients; 

update at the server the consolidated presence information for the user 
according to the status update; and 
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reflect at the server the updated consolidated presence information to the 
subscribers such that appropriate presence information is provided to 
the subscribers even if some view statuses differ. 



28. (Previously Presented) A computer program product as defined in claim 27, 
wherein updating the presence information further comprises: 

changing the presence information to offline if the status update indicates the user 
is invisible; 

refraining from changing the presence information if the status update indicates the 
user is offline; 

refraining from changing the presence information if the status update indicates the 
user is idle; 

changing the presence information to offline if the status update indicates the user 
is offline and the remaining view statuses indicate the status of the user is 
offline; 

changing the presence information to idle if the status update indicates the user is 

idle and the remaining view statuses indicate the user is idle or offline; and 
changing the presence information to match the status update. 



29. (Previously Presented) A method in a server for generating a master 
presence status of a user who is online via multiple clients at the same time, the method 
comprising: 

for each of the multiple clients through which the user is currently online, receiving 
at the server a client presence status of the user as reported by the client; 
and 

generating the master presence status representing a current presence status of 
the user based on the received client presence statuses reported by the 
multiple clients. 
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30. (Previously Presented) The method of claim 29 wherein when the client 
presence status reported by one client indicates that the user is busy and by another client 
indicates that the user idle, setting the master presence status to indicate that the user is 
busy. 

31. (Previously Presented) The method of claim 29 wherein when the client 
presence status reported by all but one client indicates that the client is offline, setting the 
master presence status to the client presence status of the client through which the user is 
currently online. 

32. (Previously Presented) The method of claim 29 including upon receiving at 
the server an indication that the client presence status of a client has changed, setting the 
master presence status based on the changed client presence status. 
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APPENDIX B 



EVIDENCE 
Applicant is not relying on any evidence. 
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APPENDIX C 



RELATED PROCEEDINGS 
Applicant is unaware of any related proceedings. 
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